home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 9380 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB
  1. Path: ix.netcom.com!news
  2. From: Henry Cross <hcross@ix.netcom.com>
  3. Newsgroups: comp.lang.c
  4. Subject: fseek() and CR/LF pair
  5. Date: Sat, 09 Mar 1996 18:25:00 -0800
  6. Organization: i586 Box @Irvine, Ca.
  7. Message-ID: <31423D7C.78A5@ix.netcom.com>
  8. NNTP-Posting-Host: irv-ca7-27.ix.netcom.com
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset=us-ascii
  11. Content-Transfer-Encoding: 7bit
  12. X-NETCOM-Date: Sat Mar 09  8:21:30 PM CST 1996
  13. X-Mailer: Mozilla 2.0 (Win95; I)
  14.  
  15. Hi boys and girls!
  16.    I got problems right here in river city! Seems my 16-bit MSDOS
  17. program using MSVC 1.52 is causing me some consternation. I have
  18. a ASCII data file I must read in in 80 byte records. Sometimes the
  19. file will have the CR/LF pair every 80th character, sometimes not.
  20. (i.e. sometimes its a text file, sometimes its a binary file.)
  21.  
  22.   I've opened the file using fopen(filename, "rb") and am getting an 
  23. erroneous position after certain  fseek's(fptr, -80L, SEEK_CUR);
  24. (i.e. I read an 80 byte record then read 1 byte to determine if
  25.  CR or LF if YES then read another byte until != CR/LF pair then
  26.  fseek -1L and read 80 bytes to determine if this record belongs
  27.  with the previous data if not then fseek(fptr, -80L, SEEK_CUR)
  28.  process the current data then return to reading 80 bytes, etc.)
  29.  
  30.  My problem is that after certain fseeks -80L where I have to back
  31. over the default 512 byte buffer boundary the file pointer is at the
  32. wrong position! Caused by the CR/LF pair and my fseek'ing backwards
  33. over a 512 byte buffer boundary even though I'm using binary mode!
  34. fseek -80L's that are within the 512 byte buffer work fine. Just don't
  35. backup past it!  I cannot create a buffer large enough with malloc and
  36. setvbuf() to read in the largest possible file. (Hey! We're talking
  37. 16 bits here! You guys remember the old 64K boundary PITA right? :) )
  38.  
  39.  I know this can happen in text mode but I fopen'ed the file in main()
  40. as "rb"!  Personally I think it's a library bug.  I ran across this
  41. problem along time ago and seem to recall I didn't have this problem
  42. with a Watcom compiler. I'm going to try another compiler but my problem
  43. is I'm stuck using MSVC at this point due to vendor library extensions.
  44. Any idea's, comments or useful insult's will be dolefully reviewed.
  45.  
  46. Thanx,
  47. H.Cross
  48.